8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags #27572

Hamlin-Li · 2025-09-30T11:25:30Z

Hi,
Can you help to review this patch?

Background

In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415), it can not be caught by the assert.

diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
index 4214d6c53dc..80896f8fffc 100644
--- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
+++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
@@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
   decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
   decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
   decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
- decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
   decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
   decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
   decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
@@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
   decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
   decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
   decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
+ decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
   decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
   decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
   decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \

If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:

# Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
# assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)

diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
index 4214d6c53dc..0ba636dce96 100644
--- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
+++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
@@ -90,8 +90,8 @@ class VM_Version : public Abstract_VM_Version {
   void update_flag() { \
       assert(enabled(), "Must be."); \
       /* dep must be declared before */ \
- assert((uintptr_t)(this) > \
- (uintptr_t)(&dep), "Invalid");\
+ assert((uintptr_t)(&dep) > \
+ (uintptr_t)(this), "Invalid: dep: %ld (%s), this: %ld (%s)", p2i(&dep), dep.pretty(), p2i(this), pretty()); \
       if (FLAG_IS_DEFAULT(flag)) { \
         if (dep.enabled()) { \
           FLAG_SET_DEFAULT(flag, true); \

But I don't think we can rely on the address of different ext_x to determine their declaration order in RV_FEATURE_FLAGS, even if the patch above can catch it.

Fix

This patch reuses RVExtFeatureValue::_cpu_feature_index as dependent_index to check the declaration order is as expected.

Test

With the following patch, it will trigger the assert:

#  Internal Error (/home/hamlin/workspace/repos/github/jdk-master-aot/src/hotspot/cpu/riscv/vm_version_riscv.hpp:120), pid=708174, tid=708177
#  assert(dependent_index() > next->dependent_index()) failed: Invalid

diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
index ae29bd36a10..8e602fb2413 100644
--- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
+++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
@@ -277,7 +277,6 @@ class VM_Version : public Abstract_VM_Version {
   decl(ext_C            ,  c           ,     ('C' - 'A'),  true ,  UPDATE_DEFAULT(UseRVC))                                 \
   decl(ext_Q            ,  q           ,     ('Q' - 'A'),  true ,  NO_UPDATE_DEFAULT)                                      \
   decl(ext_H            ,  h           ,     ('H' - 'A'),  true ,  NO_UPDATE_DEFAULT)                                      \
-  decl(ext_V            ,  v           ,     ('V' - 'A'),  true ,  UPDATE_DEFAULT(UseRVV))                                 \
   decl(ext_Zicbom       ,  Zicbom      ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT(UseZicbom))                              \
   decl(ext_Zicboz       ,  Zicboz      ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT(UseZicboz))                              \
   decl(ext_Zicbop       ,  Zicbop      ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT(UseZicbop))                              \
@@ -301,6 +300,7 @@ class VM_Version : public Abstract_VM_Version {
   decl(ext_Zvbc         ,  Zvbc        ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT_DEP(UseZvbc, &ext_V, nullptr))           \
   decl(ext_Zvfh         ,  Zvfh        ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT_DEP(UseZvfh, &ext_V, &ext_Zfh, nullptr)) \
   decl(ext_Zvkn         ,  Zvkn        ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT_DEP(UseZvkn, &ext_V, nullptr))           \
+  decl(ext_V            ,  v           ,     ('V' - 'A'),  true ,  UPDATE_DEFAULT(UseRVV))                                 \
   decl(ext_Zicond       ,  Zicond      ,  RV_NO_FLAG_BIT,  true ,  UPDATE_DEFAULT(UseZicond))                              \

Thanks!

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags (Enhancement - P4)

Reviewers

Fei Yang (@RealFYang - Reviewer)
Ludovic Henry (@luhenry - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572
$ git checkout pull/27572

Update a local copy of the PR:
$ git checkout pull/27572
$ git pull https://git.openjdk.org/jdk.git pull/27572/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27572

View PR using the GUI difftool:
$ git pr show -t 27572

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27572.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-09-30T11:27:14Z

👋 Welcome back mli! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-09-30T11:29:40Z

@Hamlin-Li This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags

Reviewed-by: fyang, luhenry

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 42 new commits pushed to the master branch:

1653999: 8369505: jhsdb jstack cannot handle continuation stub
5fc3904: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
ead35a7: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody()
... and 39 more: https://git.openjdk.org/jdk/compare/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-09-30T11:30:47Z

@Hamlin-Li The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-09-30T11:34:13Z

Webrevs

src/hotspot/cpu/riscv/vm_version_riscv.hpp

RealFYang

Thanks for the quick update. This reminds me of the order in which we enable these ISA features in RiscvHwprobe::add_features_from_query_result. In your previous PR #27562, we reorder the declarations. But we should sync RiscvHwprobe::add_features_from_query_result with that new order at the same time, right?

src/hotspot/cpu/riscv/vm_version_riscv.hpp

Hamlin-Li · 2025-10-14T12:50:06Z

Thanks for the quick update. This reminds me of the order in which we enable these ISA features in RiscvHwprobe::add_features_from_query_result. In your previous PR #27562, we reorder the declarations. But we should sync RiscvHwprobe::add_features_from_query_result with that new order at the same time, right?

Not sure if I understand you correctly.

I think it's not necessary to do so, take v and zvfh as example, if in RiscvHwprobe::add_features_from_query_result, zvfh is enabled detected and enabled before v, and v is disabled by hw probe, then in the while loop of VM_Version::setup_cpu_available_features, zvfh will still be diabled because of v disabling. So the order in theRiscvHwprobe::add_features_from_query_result will not affect the correctness of dependency check.

Or do you mean we should keep the same order of extensions and non-extensions in RiscvHwprobe::add_features_from_query_result as in RV_EXT_FEATURE_FLAGS and RV_NON_EXT_FEATURE_FLAGS for readability or some other reasons? I can also do it in this pr, just note it's not necessary to do so. :)

RealFYang · 2025-10-14T14:09:09Z

Thanks for the quick update. This reminds me of the order in which we enable these ISA features in RiscvHwprobe::add_features_from_query_result. In your previous PR #27562, we reorder the declarations. But we should sync RiscvHwprobe::add_features_from_query_result with that new order at the same time, right?

Not sure if I understand you correctly.

I think it's not necessary to do so, take v and zvfh as example, if in RiscvHwprobe::add_features_from_query_result, zvfh is enabled detected and enabled before v, and v is disabled by hw probe, then in the while loop of VM_Version::setup_cpu_available_features, zvfh will still be diabled because of v disabling. So the order in theRiscvHwprobe::add_features_from_query_result will not affect the correctness of dependency check.

Or do you mean we should keep the same order of extensions and non-extensions in RiscvHwprobe::add_features_from_query_result as in RV_EXT_FEATURE_FLAGS and RV_NON_EXT_FEATURE_FLAGS for readability or some other reasons? I can also do it in this pr, just note it's not necessary to do so. :)

Here is what I am thinking: Your verify_deps only ensures that the declarations of the extensions are in the correct order (as indicated by the _cpu_feature_index). And that is the order in which we should follow when enabling these extensions. So for this to work, the order should be refected by RiscvHwprobe::add_features_from_query_result which does the work. For safety, I think we should always sync them. Make sense?

Hamlin-Li · 2025-10-14T15:16:03Z

Here is what I am thinking: Your verify_deps only ensures that the declarations of the extensions are in the correct order (as indicated by the _cpu_feature_index). And that is the order in which we should follow when enabling these extensions. So for this to work, the order should be refected by RiscvHwprobe::add_features_from_query_result which does the work. For safety, I think we should always sync them. Make sense?

OK, I'll reorder it.

openjdk · 2025-10-14T15:18:16Z

⚠️ @Hamlin-Li This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

RealFYang

Latest version LGTM. Thanks.

src/hotspot/cpu/riscv/vm_version_riscv.hpp

Hamlin-Li · 2025-10-16T14:01:46Z

Thanks for your reviewing!

Hamlin-Li · 2025-10-16T14:02:01Z

/integrate

openjdk · 2025-10-16T14:04:54Z

Going to push as commit f475eb8.
Since your change was applied there have been 42 commits pushed to the master branch:

1653999: 8369505: jhsdb jstack cannot handle continuation stub
5fc3904: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
ead35a7: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody()
... and 39 more: https://git.openjdk.org/jdk/compare/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-10-16T14:05:06Z

@Hamlin-Li Pushed as commit f475eb8.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

hamlin and others added 11 commits September 12, 2025 09:04

initial commit

e27247b

Merge branch 'openjdk:master' into master

4a75e87

Merge branch 'openjdk:master' into master

4ee1df1

Merge branch 'openjdk:master' into master

0ff5e42

Merge branch 'openjdk:master' into master

924c4c9

Merge branch 'openjdk:master' into master

75dee02

Merge branch 'openjdk:master' into master

57973f4

Merge branch 'openjdk:master' into master

4b058ce

Merge branch 'openjdk:master' into master

b73a502

initial commit

fab9dba

initial commit

3205c38

Hamlin-Li mentioned this pull request Sep 30, 2025

8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS #27562

Closed

3 tasks

openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 30, 2025

openjdk bot added the rfr Pull request is ready for review label Sep 30, 2025

Hamlin-Li added 2 commits October 1, 2025 11:17

Merge branch 'openjdk:master' into master

8eba0c0

Merge branch 'openjdk:master' into master

7f36f23

RealFYang reviewed Oct 14, 2025

View reviewed changes

src/hotspot/cpu/riscv/vm_version_riscv.hpp Outdated Show resolved Hide resolved

src/hotspot/cpu/riscv/vm_version_riscv.hpp Outdated Show resolved Hide resolved

src/hotspot/cpu/riscv/vm_version_riscv.hpp Outdated Show resolved Hide resolved

hamlin added 2 commits October 14, 2025 09:49

only verify_deps when debug

a2bdd92

move dependency checks into RVExtFeatureValue

8da2ee7

RealFYang reviewed Oct 14, 2025

View reviewed changes

src/hotspot/cpu/riscv/vm_version_riscv.hpp Outdated Show resolved Hide resolved

rename

58627d3

Merge branch 'openjdk:master' into master

3089ec9

Merge branch 'master' into fix-out-of-order-declarations

d9478cd

reorder

d8f39f7

RealFYang approved these changes Oct 15, 2025

View reviewed changes

src/hotspot/cpu/riscv/vm_version_riscv.hpp Outdated Show resolved Hide resolved

openjdk bot added the ready Pull request is ready to be integrated label Oct 15, 2025

minor

a1dd8de

openjdk bot removed the ready Pull request is ready to be integrated label Oct 15, 2025

RealFYang approved these changes Oct 15, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Oct 15, 2025

luhenry approved these changes Oct 16, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Oct 16, 2025

openjdk bot closed this Oct 16, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 16, 2025

8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags #27572

8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags #27572

Uh oh!

Conversation

Hamlin-Li commented Sep 30, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

Fix

Test

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Sep 30, 2025

Uh oh!

openjdk bot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RealFYang left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Hamlin-Li commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RealFYang commented Oct 14, 2025

Uh oh!

Hamlin-Li commented Oct 14, 2025

Uh oh!

openjdk bot commented Oct 14, 2025

Uh oh!

RealFYang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Hamlin-Li commented Oct 16, 2025

Uh oh!

Hamlin-Li commented Oct 16, 2025

Uh oh!

openjdk bot commented Oct 16, 2025

Uh oh!

openjdk bot commented Oct 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Hamlin-Li commented Sep 30, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Sep 30, 2025 •

edited

Loading

openjdk bot commented Sep 30, 2025 •

edited

Loading

mlbridge bot commented Sep 30, 2025 •

edited

Loading

RealFYang left a comment •

edited

Loading

Hamlin-Li commented Oct 14, 2025 •

edited

Loading